Make UAVCAN transport layer capable of sending/receiving messages from custom CAN protocols#16
Open
duartecdias wants to merge 12 commits intodronecan:mainfrom
Open
Make UAVCAN transport layer capable of sending/receiving messages from custom CAN protocols#16duartecdias wants to merge 12 commits intodronecan:mainfrom
duartecdias wants to merge 12 commits intodronecan:mainfrom
Conversation
added 12 commits
September 3, 2023 14:27
together with UAVCAN protocol. Each iface is defined a protocol, allowing the sending of messages just for that specific protocol (this selection is done by the dispatcher).
listeners, so it is more versatile when considering different protocols.
that there is less protection since we assume the protocol identifier is now an integer.
Contributor
|
@duartecdias thanks! I think you can squash pretty much all the commits since we had the whole KDE protocl in here initially. The motivation for this change in our case was specifically to add KDECAN support. However I came accross numerous use-cases in the past that were simpler. Industry sensors with very basic CAN protocols exist that can be implemented alongside Dronecan like this. Either on the same interface (if rules for splitting messages can be found, the simplest split is 11bit vs 29bit identifiers) or on separate interfaces. We're now flying with KDE ESCs and KitCANs running on the same bus without issues. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
A custom protocol can operate through the UAVCAN transport layer by using the CustomTransferListener and CustomTransferSender classes. This was tested using an implementation of the KDECAN protocol in the uavcan driver, in the following public branch: https://github.com/duartecdias/PX4-Autopilot/tree/pr/uavcan/kdecanProtocol
It also associates a specific CAN protocol to a specific CAN interface. Messages of a specific CAN protocol will not be sent from a CAN interface associated to a different protocol. In addition, UAVCAN messages will not be read in case the receiving CAN interface is not associated to the UAVCAN protocol. By default, UAVCAN protocol is associated to both CAN interfaces. In this case, all UAVCAN messages will be sent, and all UAVCAN messages will be read.
Additionally, the implementation also allows for a way to send/receive messages of a custom CAN protocol implemented using standard ids, without having to change the interface protocol (this assumes UAVCAN uses only 29bits - extended - Ids, as described in: https://legacy.uavcan.org/Specification/4._CAN_bus_transport_layer/).
Tests were conducted in the above public branch (https://github.com/duartecdias/PX4-Autopilot/tree/pr/uavcan/kdecanProtocol). These tests are the following:
-prepare a normal quadrotor setup in a cubeorange (can disable GPS, etc. to make it arm). Configure UAVCAN ESC parameters.
-set extra CAN device (e.g. Kitcan)
-set debug Zubax device.
-connect everything on CAN interface 1 (monitor only interface 1)
-Turn ON cubeorange. Confirm sent of motor commands while listening to extra UAVCAN devices - debug with Zubax device.
-Different parameter configurations
-ESC_PROTO: 0, CAN1_PROTO: 0, CAN2_PROTO: 0 (PASS)
Description: ESCs use UAVCAN protocol and interfaces 1, 2 are configured to use UAVCAN
Expected behavior: send UAVCAN motors commands, receive Kitcan messages
-ESC_PROTO: 1, CAN1_PROTO: 0, CAN2_PROTO: 0, KDECAN (PASS)
Description: ESCs use KDECAN protocol and and interfaces 1, 2 are configured to use UAVCAN
Expected behavior: send KDECAN motor commands (standard Ids), receive Kitcan messages
-ESC_PROTO: 1, CAN1_PROTO: 1, CAN2_PROTO: 0, KDECAN (PASS)
Description: ESCs use KDECAN protocol, interface 1 uses KDECAN while interface 2 uses UAVCAN
Expected behavior: send KDECAN motor commands (extended Ids), filter/discard Kitcan messages
-Confirm reception of KDECAN ESC feedback (PASS)
-Confirm correct operation through multiple power cycles (PASS)